1. Field of the Invention
The present disclosure generally relates to source control systems. In particular, the present disclosure relates to version control, templates, automatic check-out, process automation, and other applications and features.
2. Discussion of the Background Art
Source control is also known as configuration management or change management. Source control is a discipline of making changes to source code in a planned and systematic fashion. The purpose of source control is to formally control the integrity of artifacts (items) and activities (tasks). Source control has four primary activities: identification, management, status accounting, and auditing.
Identification is the task of identifying (documenting/baselining) artifacts, i.e. the items or objects that make up systems. Some artifacts include software, hardware, and firmware.
Management is the introduction of controls (procedures and quality gates) to ensure products or systems evolve appropriately. Some example areas of focus include deployment and release practices, issue tracking practices, change request practices, asset management practices, and system management practices.
Status accounting is capturing configuration management data, processing data, and using the information. The objective is to provide information to support management and decision making. Some example groups and individuals that benefit from this information are configuration management, security, quality assurance, project managers, and engineers.
Auditing is reviewing the organizational process against the defined or required standards. Some areas of focus include adherence to process, conformance to security, and configuration verification. The purpose of auditing is continual optimization. Auditing is a review that leads to recommendations and corrective updates to the process.
The items under control in a source control system include objects, such as control strategies. In object-oriented programming (OOP), objects are abstractions used in designing a program and they are also the units of code that are eventually derived from the design process. In between, each object is made into a generic class of object and even more generic classes are defined so that objects can share models and reuse the class definitions in their code. Each object is an instance of a particular class or subclass with the class' own methods or procedures and data variables. Thus, objects typically exist in a hierarchy of objects with parent and child relationships. An object is usually a binary, text, or other type of file.
In a source control system, objects are checked-out, edited, and then checked-in. Each time an object is checked-in, it is given a version number. Over time, a history of changes is created for the objects under the control of the source control system.
There is a need for a way to prevent unauthorized changes to dependent objects under control of a source control system, while maintaining the change propagation feature of the parent object, and to eliminate the necessity for a user to determine what the dependencies are for the object, which is time-consuming and error-prone. There is a need for a method to keep track of the information that is necessary to correctly establish the dependencies between parent objects and other objects. This information would then be used by the system to determine what objects must be checked-out, i.e. marked as okay to edit, of the source control system when a parent object is checked-out. The dependent objects would then automatically be checked-out without requiring any user intervention. Then, any changes that are made to the parent object would be propagated to the dependent objects.